home *** CD-ROM | disk | FTP | other *** search
- Path: chronicle.mti.sgi.com!austern
- From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
- Newsgroups: comp.std.c++
- Subject: #error (was: Re: #warning)
- Date: 22 Feb 1996 10:14:55 PST
- Organization: Comp Sci, University of Melbourne
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <4gibn8$6pg@mulga.cs.mu.OZ.AU>
- References: <4g91rh$kgn@mulga.cs.mu.OZ.AU> <4gdcvn$cqv@engnews1.Eng.Sun.COM>
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: 22 Feb 1996 18:12:56 GMT
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMSyyzEy4NqrwXLNJAQGkKwH+NZP6XPPsaOKNpIb7B/RPYkaPwcRCVd5z
- Kkb+au26uAAuEle9OwG8O9ZK9LdkRx8iqkAk9KdltE9bmqLs/KLM4Q==
- =RW/c
- Originator: austern@isolde.mti.sgi.com
-
- clamage@Eng.sun.com (Steve Clamage) writes:
-
- >fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
- >>clamage@Eng.Sun.COM (Steve Clamage) writes:
- >>>
- >>>The description of #error says only that it
- >>>"causes the implementation to produce a diagnostic message that includes
- >>>the specified sequence of preprocessing tokens."
- >>
- >>Isn't this a bug in the standard? Doesn't this mean that
- >>
- >> #error foobar
- >> int main() { return 0; }
- >>
- >>is a strictly conforming program? Yet no compiler I know of will accept it!
- >
- >It is a strictly conforming program (although we don't use that terminology
- >in the C++ standard).
-
- OK, so we are agreed so far.
-
- >The implementation must tell you what the effect of #error is.
-
- What makes you think that? As far as I can tell, it is not in the
- least bit justified by the draft standard. Here's the complete
- description of #error:
-
- | 16.5 Error directive [cpp.error]
- |
- | 1 A preprocessing directive of the form
- | # error pp-tokensopt new-line
- | causes the implementation to produce a diagnostic message that
- | includes the specified sequence of preprocessing tokens.
-
- It doesn't say anything about implementation-defined behaviour or the
- implementation being required to document anything.
-
- >If the effect is to abort compilation, that is allowed.
-
- Again, what makes you think that?
-
- Is the implementation allowed to abort compilation if it sees a #define?
-
- >>Surely the semantics specified for #error should say that it has the effect
- >>of making the translation unit ill-formed.
- >
- >Why?
-
- So that you can be sure that a translation unit with #error in it will
- not be accepted by any sane implementation.
-
- >You can write ill-formed code if you want to. For example:
- > #if undesirable_condition
- > this phrase should not be seen by the compiler
- > #endif
-
- But I shouldn't have to. I'd much rather write just
-
- #if undesirable_condition
- #error "undesirable_condition occurred"
- #endif
-
- than
-
- #if undesirable_condition
- this phrase should not be seen by the compiler
- #endif
-
- or
-
- #if undesirable_condition
- #error "undesirable_condition occurred"
- this phrase should not be seen by the compiler
- #endif
-
- and I would still like to be sure that conforming compilers do not accept
- the code if undesirable_condition is true.
-
- According to the current wording, conforming compilers are *required*
- to accept #error!
-
- Obviously this is a mistake; it needs to be fixed.
-
- >The #error directive is part of the language, and I think it would be a
- >contradiction in terms to say that a valid language construct is ill-formed.
-
- The #error itself is not ill-formed; the translation unit containing it is,
- unless the #error is skipped via conditional compilation. There is no
- contradiction there.
-
- --
- Fergus Henderson WWW: http://www.cs.mu.oz.au/~fjh
- fjh@cs.mu.oz.au PGP: finger fjh@128.250.37.3
- ---
- [ To submit articles: Try just posting with your newsreader. If that fails,
- use mailto:std-c++@ncar.ucar.edu
- FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
- Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu
- ]
-